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This is an appeal from the final rejection set forth in an Official Action dated 
September 3, 2008, ("the Final Office Action") finally rejecting claims 1-6, and 8-36, all of 
the claims pending in this application, as being unpatentable over 3 rd Generation 
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I. REAL PARTY IN INTEREST 
The real party in interest in this application is Nokia Siemens Networks Oy of 
Espoo, Finland, by virtue of an Assignment by Nokia Corporation, which assignment was 
recorded at Reel 020550, Frame 0001, on February 21, 2008. Nokia Corporation has 
received its interest by virtue of an Assignment by the inventors, recorded at Reel 
014980, Frame 0456, on February 12, 2004. 

II. RELATED APPEALS AND INTERFERENCES 
There are no known related appeals and/or interferences which will directly effect 
or be directly effected by or have a bearing on the Board's decision in this appeal. 

III. STATUS OF CLAIMS 
Claims 1-6, and 8-36, all of the claims pending in the present application are the 
subject of this appeal. Claims 1-6 and 8-36 were rejected under 35 U.S.C. § 103(a) as 
allegedly being unpatentable over 3GPP in view of Kett. Claim 7 was previously 
cancelled by Appellants. 

IV. STATUS OF AMENDMENTS 
All of claims 1-6 and 8-36 stand as they were previously presented prior to the 
Final Office Action. No amendments were made after the final rejection. Thus, claims 
1-6 and 8-36 are pending and their respective rejections of claims 1-6 and 8-36 are 
appealed. A response was filed on December 1, 2008, and was entered, but the 

3 



response did not include any amendments to the claims. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 
Claim 1 , upon which claims 2-6 are dependent, recites a method of deactivating 
a service account associated with an application server of a registered subscriber within 
a signaling network supporting internet protocol based services. (Specification at least 
at page 4, lines 11-13, page 7, lines 3-8, Figure 2). The method includes monitoring a 
status of a service account. (Specification at least at page 4, line 14, page 7, lines 8-9, 
Figure 2). The method further includes forwarding a request for de-registration from said 
application server via a direct interface to a registration server, which maintains a 
registration status of said subscriber, upon determining that disruption or termination of 
service is required. (Specification at least at page 4, lines 15-18, page 7, lines 9-12, 
Figure 2, "1 . PUR"). The method further includes changing the registration status of said 
subscriber so as to de-register said subscriber at said registration server in response to 
said de-registration request. (Specification at least at page 4, lines 19-21, page 7, lines 
12-14, Figure 2, "2. De-registration"). 

Claim 8, upon which claims 9-10 are dependent, recites a system for deactivating 
a service account of a registered subscriber within a signaling network supporting internet 
protocol based services. (Specification at least at page 4, lines 24-26, page 7, lines 3-8, 
Figure 2). The system includes a registration server configured to maintain a registration 
status of said subscriber. (Specification at least at page 4, lines 27-28, page 7, lines 6-7, 
Figure 2, "HSS 20"). The system further includes an application server, to which said 
service account is associated, configured to monitor a status of said service account and 
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to forward via a direct interface a request for de-registration to said registration server, 
upon determining that disruption or termination of service is required. (Specification at 
least at page 4, line 29 - page 5, line 3, page 7, lines 8-12, Figure 2, "AS 60"). The 
registration server is configured to change the registration status of said subscriber so as 
to de-register said subscriber in response to said de-registration request. (Specification 
at least at page 5, lines 4-7, page 7, lines 12-15, Figure 2, "HSS 20"). 

Claim 11, upon which claims 12-14 and 18-19 are dependent, recites a method of 
deactivating a service account associated with an application server of a registered 
subscriber within a signaling network supporting internet protocol based services. 
(Specification at least at page 4, lines 11-13, page 7, lines 3-8, Figure 3). The method 
includes monitoring a status of said service account. (Specification at least at page 4, 
line 14, page 7, lines 8-9, Figure 3). The method further includes forwarding a request for 
barring from said application server via a direct interface to a registration server, which 
maintains a registration status of said subscriber, upon determining that disruption or 
termination of service is required. (Specification at least at page 4, lines 15-18, page 7, 
lines 9-12, Figure 3, "2. PUR"). The method further includes changing a barring indication 
of said subscriber so as to bar said subscriber at said registration server by changing said 
barring indication in response to said barring request. (Specification at least at page 4, 
lines 19-21, page 7, lines 12-14, Figure 3, "2. data update"). 

Claim 15 recites a system for deactivating a service account of a registered 
subscriber within a signaling network supporting internet protocol based services. 
(Specification at least at page 4, lines 24-26, page 7, lines 3-8, Figure 3). The system 
includes a registration server configured to maintain a registration status of said 
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subscriber. (Specification at least at page 4, lines 27-28, page 7, lines 6-7, Figure 3 "HSS 
20"). The system further includes an application server, to which said service account is 
associated, configured to monitor a status of said service account and to forward via a, 
direct interface a request for barring to said registration server, upon determining that 
disruption or termination of service is required. (Specification at least at page 4, line 29 
- page 5, line 3, page 7, lines 8-12, Figure 3, "AS 60"). The registration server is 
configured to change a barring indication of said subscriber to bar said subscriber in 
response to said barring request. (Specification at least at page 5, lines 4-7, page 7, lines 
12-15; Figure 3, "HSS 20"). 

Claim 16 recites a system for deactivating a service account associated with an 
application server of a registered subscriber within a signaling network supporting 
internet protocol based services. (Specification at least at page 4, lines 24-26, page 7, 
lines 3-8, Figure 2). The system includes monitoring means for monitoring a status of 
said service account. (Specification at least at page 7, lines 6-7, Figure 2, "AS 60"). The 
system further includes forwarding means for forwarding a request for de-registration 
from said application server via a direct interface to a registration server, which maintains 
a registration status of said subscriber, upon determining that disruption or termination of 
service is required. (Specification at least at page 7, lines 8-12, Figure 2, "AS 60" and 
"HSS 20"). The system further includes changing means for changing the registration 
status of said subscriber so as to deregister said subscriber at said registration server in 
response to de-registration request. (Specification at least at page 7, lines 12-15, Figure 
2, "HSS 20"). 

Claim 17 recites a system for deactivating a service account associated with an 
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application server of a registered subscriber within a signaling network supporting 
internet protocol based services. (Specification at least at page 4, lines 24-26, page 7, 
lines 3-8, Figure 3). The system includes monitoring means for monitoring a status of 
said service account. (Specification at least at page 7, lines 6-7, Figure 3, "AS 60"). The 
system further includes forwarding means for forwarding a request for barring from said 
application server via a direct interface to a registration server, which maintains a 
registration status of said subscriber, upon determining that disruption or termination of 
service is required. (Specification at least at page 7, lines 8-12, Figure 3, "AS 60" "HSS 
20"). The system further includes changing means for changing a barring indication of 
said subscriber so as to bar said subscriber at said registration server by changing said 
barring indication in response to said barring request. (Specification at least at page 7, 
lines 12-15; Figure 3, "HSS 20"). 

Claim 20, upon which claims 21-24 are dependent, recites a method of 
deactivating a service account associated with an application server of a registered 
subscriber within a signaling network supporting internet protocol based services. 
(Specification at least at page 4, lines 11-13, page 7, lines 3-8, Figure 2). The method 
includes monitoring a status of a service account. (Specification at least at page 4, line 
14, page 7, lines 8-9, Figure 2). The method further includes forwarding a request for 
de-registration from said application server via a direct interface to a registration server 
upon determining that disruption or termination of service is required. (Specification at 
least at page 4, lines 15-18, page 7, lines 9-12, Figure 2, "1. PUR"). The registration 
server maintains a registration status of said subscriber. (Specification at least at page 
4, lines 15-18, page 7, lines 9-12, Figure 2, "1. PUR," "HSS 20"). The registration server 
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changes said registration status of said subscriber so as to de-register said subscriber at 
said registration server in response to said de-registration request. (Specification at least 
at page 4, lines 19-21, page 7, lines 12-14, Figure 2, "2. De-registration," "HSS 20"). 

Claim 25, upon which claim 26 is dependent, recites a method of deactivating a 
sen/ice account associated with an application server of a registered subscriber within a 
signaling network supporting internet protocol based services. (Specification at least at 
page 4, lines 11-13, page 7, lines 3-8, Figure 2). The method includes receiving from said 
application server via a direct interface a request for de-registration at a registration 
server, which maintains a registration status of said subscriber. (Specification at least at 
page 4, lines 15-18, page 7, lines 9-12, Figure 2, "1. PUR," "HSS 20"). The method, 
further includes changing the registration status of said subscriber so as to de-register 
said subscriber at said registration server in response to said de-registration request. 
(Specification at least at page 4, lines 19-21, page 7, lines 12-14, Figure 2, "2. 
De-registration," "HSS 20"). 

Claim 27, upon which claims 28-29 are dependent, recites a method of 
deactivating a service account associated with an application server of a registered 
subscriber within a signaling network supporting internet protocol based services. 
(Specification at least at page 4, lines 11-13, page 7, lines 3-8, Figure 3). The method 
includes monitoring a status of said service account. (Specification at least at page 4, 
line 14, page 7, lines 8-9, Figure 3). The method further includes forwarding a request for 
barring from said application server via a direct interface to a registration server upon 
determining that disruption or termination of service is required. (Specification at least at 
page 4, lines 15-18, page 7, lines 9-12, Figure 3, "2. PUR"). The registration server 
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maintains a registration status of said subscriber. (Specification at least at page 4, lines 
15-18, page 7, lines 9-12, Figure 3, "2. PUR," "HSS 20"). The registration server changes 
a barring indication of said subscriber so as to bar said subscriber at said registration 
server by changing said barring indication in response to said barring request. 
(Specification at least at page 4, lines 19-21, page 7, lines 12-14, Figure 3, "2. data 
update"). 

Claim 30, upon which claim 31 is dependent recites, a method of deactivating a 
service account associated with an application server of a registered subscriber within a 
signaling network supporting internet protocol based services. (Specification at least at 
page 4, lines 11-13, page 7, lines 3-8, Figure 3). The method includes receiving from said 
application server via a direct interface a request for barring to a registration server, which 
maintains a registration status of said subscriber. (Specification at least at page 4, lines 
15-18, page 7, lines 9-12, Figure 3, "2. PUR," "HSS 20"). The method further includes 
changing a barring indication of said subscriber so as to bar said subscriber at said 
registration server by changing said barring indication in response to said barring request. 
(Specification at least at page 4, lines 19-21, page 7, lines 12-14, Figure 3, "2. data 
update"). 

Claim 32, upon which claim 33 is dependent, recites a registration server for 
deactivating a service account of a registered subscriber. (Specification at least at page 
7, lines 3-8, Figure 2, "HSS 20"). The registration server includes a storage configured to 
maintain a registration status of said subscriber. (Specification at least at page 7, lines 
4-5, Figure 2, "HSS 20"). The registration server further includes an updating unit 
configured to change the registration status of said subscriber so as to de-register said 
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subscriber in response to a de-registration request forwarded from an application server 
via a direct interface to said registration server (Specification at least at page 7, lines 
9-13, page 7, line 20 - page 8, line 3, Figure 2, 'HSS 20"). 

Claim 34 recites a registration server for deactivating a service account of a 
registered subscriber. (Specification at least at page 7, lines 3-8, Figure 2, "HSS 20"). 
The registration server includes means for maintaining a registration status of said 
subscriber. (Specification at least at page 7, lines 4-5, Figure 2, "HSS 20"). The 
registration server further includes means for changing the registration status of said 
subscriber so as to de-register said subscriber in response to a de-registration request 
forwarded from an application server via a direct interface to said registration server. 
(Specification at least at page 7, lines 9-13, page 7, line 20 - page 8, line 3, Figure 2, 
'HSS 20"). 

Claim 35 recites an application server for deactivating a service account of a 
registered subscriber. (Specification at least at page 7, lines 3-6, Figure 2, "AS 60"). The 
application server includes a forwarding unit configured to forward a request for 
de-registration from said application server via a direct interface to a registration server, 
upon determining that disruption or termination of service is required. (Specification at 
least at page 7, lines 9-12, page 7, lines 18-24, Figure 2, "AS 60"). 

Claim 36 recites an application server for deactivating a service account of a 
registered subscriber. (Specification at least at page 7, lines 3-6, Figure 2, "AS 60"). The 
application server includes means for monitoring a status of said service account. 
(Specification at least at page 7, lines 9-10, Figure 2, "AS 60"). The application server 
further includes means for forwarding a request for de-registration from said application 
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server via a direct interface to a registration server, upon determining that disruption or 
termination of service is required. (Specification at least at page 7, lines 9-12, page 7, 
lines 18-24, Figure 2, "AS 60"). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 
The grounds of rejection to be reviewed on appeal are the rejection of claims 1-6 
and 8-36 under 35 U.S.C. § 103(a) as allegedly being unpatentable over 3GPP in view 
of Kett. As will be discussed below, this rejection is in error, and claims 1-6 and 8-36 
should all be found to meet the U.S. requirements for patentability under 35 U.S.C. § 1 03. 

VII. ARGUMENT 

Appellants respectfully submit that each of the pending claims 1-6 and 8-36 recites 
patentable subject matter that is not taught, disclosed, or suggested by the cited art. 
Each of the claims is being argued separately, and thus, each of the claims stands or falls 
alone. 

In the Final Office Action, claims 1-6 and 8-36 were rejected under 35 U.S.C. § 
103(a) as being unpatentable over 3GPP in view of Kett. Appellants submit that each of 
claims 1-6 and 8-36 recite subject matter that is not obvious in light of 3GPP and Kett, 
and as such, the Board's reversal of the rejection is respectfully requested. 

i) Claim 1 

Claim 1 , upon which claims 2-6 are dependent, recites a method of deactivating 
a service account associated with an application server of a registered subscriber within 
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a signaling network supporting internet protocol based services. The method includes 
monitoring a status of a service account. The method further includes forwarding a 
request for de-registration from said application server via a direct interface to a 
registration server, which maintains a registration status of said subscriber, upon 
determining that disruption or termination of sen/ice is required. The method further 
includes changing the registration status of said subscriber so as to de-register said 
subscriber at said registration server in response to said de-registration request. 

Applicants respectfully submit that 3GPP and Kett, whether considered 
individually or in combination, fail to disclose, or suggest, all the elements of claim 1. 

3GPP identifies a stage-2 service description for a Internet Protocol (IP) 
Multimedia Core Network Subsystem (IMS), including the elements necessary to support 
IP Multimedia (IM) services in UMTS. ITU-T Recommendation 1.130 describes a 
three-stage method for characterization of telecommunication services, and ITU-T 
Recommendation Q.65 defines stage 2 of the method. 3GPP identifies the mechanisms 
to enable support for IP multimedia applications. (See 3GPP at "Scope"). 

Kett describes a registration server implementing an application programming 
interface (API) which authenticates services and provides discover of network resources, 
prior to registering services with selected network resources. Specifically, with respect to 
Figure 4, Kett describes the interfaces between components of the network implementing 
the Parlay interface. The interface is object-oriented and is implemented using service 
interfaces and framework interfaces. The service interfaces of application provide 
access to the capabilities of the network. The framework interfaces provide a surround 
for the service interfaces and implements processes of authentication, discovery, and 
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registration. There is a direct interface 4.2 between client applications and Parlay 
services. The direct interface is only accessed after an application has signed-on via the 
framework interface 4.1. (See Kett at Abstract and paragraph 0030). 

The Final Office Action took the position that 3GPP discloses all the elements of 
claim 1 , with the exception of "connecting from an application server to a registration 
server via a direct interface." The Final Office Action then cited Kett as allegedly curing 
the deficiencies of 3GPP. (See Final Office Action at pages 3-4). Appellants respectfully 
submit that the rejection is erroneous because, as will be discussed in further detail, 
3GPP and Kett, whether considered individually or in combination, fail to disclose, or 
suggest, at least, "forwarding a request for de-registration from said application server via 
a direct interface," as recited in claim 1 . 

The Final Office Action correctly concluded that 3GPP fails to disclose or suggest 
a direct interface between an application server and a registration server via a direct 
interface. (See Final Office Action at pages 3-4). Thus, there is no dispute that 3GPP 
fails to disclose, or suggest, at least, the aforementioned element of claim 1. 

Furthermore, contrary to the Final Office Action's position, Kett does not cure the 
deficiencies of 3GPP. As previously discussed, Kett describes a registration server 
implementing an application programming interface (API) which authenticates services 
and provides discover of network resources, prior to registering services with selected 
network resources. A network which includes an API between service components 
embedded in the network and applications running at the edge of the network has been 
developed by the Parlay Organization ("Parlay interface"). (See Kett at paragraph 0005). 
Kett discloses a communications network which includes an access network 1 , a core 
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network 2, and a registration server 5 connected to the network, and used in 
implementing an API to network resources (i.e. a Parlay interface). (See Kett at 
paragraph 0027). The Parlay interface is objection-oriented and is implemented using 
service interfaces and framework interfaces. The service interface provide applications 
access to the network. The framework interface implements processes of authentication, 
discovery, and registration. As illustrated in Figure 4 of Kett, there is a direct interface 4.2 
between client applications and Parlay services. However, these direct interfaces 4.2 are 
only accessed after an application has signed-on via the framework interface 4.1 . (See 
Kett at paragraph 0030, Figure 4). 

The Final Office Action cites paragraphs 0030-0033 of Kett as allegedly disclosing 
a direct interface between an application server and a registration server. (See Final 
Office Action at page 4). However, Appellants respectfully submit that neither framework 
interface 4.1, nor direct interface 4.2 disclose, or suggest, a direct interface between an 
application server and a registration server. Specifically, framework interface 4.1 is an 
interface between the framework objects in the network domain and the client framework 
objects in the user domain, and is not an interface between an application server and a 
registration server. Furthermore, direct interface 4.2 is an interface between a client 
application and a Parlay service of the Parlay API, and is also not an interface between 
an application server and a registration. Instead, the client application signs-on with the 
Parlay API via the registration server. A Parlay authentication objection is instantiated on 
the registration server and provides an authentication interface that enables mutual 
authentication of the registration server and the client application. (See Kett at 
paragraphs 0030 and 0032; Figure 4). 
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The Advisory Action took the position that Kett is relied upon to teach the element 
of the claim "via a direct interface." (See Advisory Action at page 2). However, 
independent claim 1 clearly recites "forwarding a request for de-registration from said 
application server via a direct interface to a registration server ." Thus, the plain language 
of the claim indicates that the direct interface is between the application server and the 
registration server . As previously discussed, Kett fails to disclose, or suggest, a direct 
interface between an application server and a registration server. Thus, Kett fails to 
disclose, or suggest, at least, "forwarding a request for de-registration from said 
application server via a direct interface," as recited in claim 1 . 

Furthermore, Appellants respectfully submit that the Final Office Action's 
statement that one of ordinary skill in the art would be motivated to combine the 
references of 3GPP and Kett to arrive at the claimed invention to improve the function 
and performance of API implementation in a communication network fails to take into 
account the substantial differences between Kett and the claimed invention. (See Final 
Office Action at Page 4). For example, Kett teaches a registration procedure, rather than 
a de-registration procedure, and Kett also teaches an API implementation . Thus, the 
stated motivation would lead to an API implementation in the registration procedure of the 
3GPP configuration, and not to a direct interface between an application server and a 
registration server , as recited in claim 1 . 

Appellants further submit there is no motivation or suggestion in 3GPP which 
would allow a person of ordinary skill in the art to use the teaching of a registration 
procedure based on an API implementation , such as disclosed in Kett, in order to provide 
the de-registration or barring procedure of the claimed invention. Likewise, there is no 
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motivation or suggestion in Kett which would allow a person of ordinary skill in the art to 
use the teaching of a de-registration procedure without API implementation , such as 
disclosed in 3GPP, in order to provide the de-registration or baring procedure of the 
claimed invention. 

Accordingly, Appellants respectfully submit that 3GPP and Kett, whether 
considered individually or in combination, fail to disclose, or suggest, "forwarding a 
request for de-registration from said application server via a direct interface," as recited in 
claim 1. Therefore, it is respectfully requested that this rejection be reversed and the 
claim allowed. 

ii) Claim 2 

Claim 2 is dependent on claim 1, and recites further limitations. Thus, claim 2 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. 

Specifically, claim 2 recites "wherein said forwarding step comprises forwarding 
said request over said interface directly coupling said application server and said 
registration server." The Final Office Action relied upon two separate portions of 3GPP to 
support its erroneous position that 3GPP discloses the aforementioned limitation. The 
Final Office Action first relied upon page 43, Figure. 5.5a as allegedly disclosing 
forwarding a request, and relied upon pages 14-17, Section 4.2.4 as allegedly disclosing 
an interface directly coupling an application server and an registration server. (See Final 
Office Action at page 4). Section 4.2.4 describes an ISC interface between a Serving 
CSCF and a service platform, and Sh and Si interfaces used for communications 
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between the application server and the home subscriber server ("HSS"). (See 3GPP at 
pages 14-17, Section 4.2.4). However, 3GPP fails to describe a registration message 
being sent over the Sh and Si interfaces. Instead, 3GPP merely describes that the 
S-CSCF receives de-registration information from the service platform and issues a 
de-registration towards the P-CSCF. (See 3GPP at page 43, section 5.3.2.2.2, Figure 
4.4a). Because the claim explicitly recites that the request is forwarded over the interface 
directly coupling the application server and the registration server, Appellants respectfully 
submit that 3GPP fails to disclose, or suggest, the aforementioned limitation. 
Furthermore, Kett fails to cure the deficiencies of 3GPP because, as previously 
discussed, Kett merely discusses a direct interface between an application and a Parlay 
service, and fails to disclose an interface directly coupling an application server and a 
registration server. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

iii) Claim 3 

Claim 3 is dependent on claim 1 , and recites further limitations. Thus, claim 3 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

iv) Claim 4 

Claim 4 is dependent on claim 1 , and recites further limitations. Thus, claim 4 is 

17 



patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

v) Claim 5 

Claim 5 is dependent on claim 1, and recites further limitations. Thus, claim 5 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

vi) Claim 6 

Claim 6 is dependent on claim 1, and recites further limitations. Thus, claim 6 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

vii) Claim 8 

Claim 8 recites a system for deactivating a service account of a registered 
subscriber within a signaling network supporting internet protocol based services. The 
system includes a registration server configured to maintain a registration status of said 
subscriber. The system further includes an application server, to which said service 
account is associated, configured to monitor a status of said service account and to 
forward via a direct interface a request for de-registration to said registration server, upon 
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determining that disruption or termination of service is required. The registration server is 
configured to change the registration status of said subscriber so as to de-register said 
subscriber in response to said de-registration request. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "an application server, to which said service account is associated, configured to 
monitor a status of said service account and to forward via a direct interface a request for 
de-registration to said registration server," as recited in claim 8 for similar reasons as to 
why the combination of 3GPP and Kett fails to disclose, or suggest, at least, "forwarding 
a request for de-registration from said application server via a direct interface," as recited 
in claim 1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

viii) Claim 9 

Claim 9 is dependent on claim 8, and recites further limitations. Thus, claim 9 is 
patentable at least for the reasons claim 8 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

ix) Claim 10 

Claim 10 is dependent on claim 8, and recites further limitations. Thus, claim 10 is 

19 



patentable at least for the reasons claim 8 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

x) Claim 1 1 

Claim 1 1 recites a method of deactivating a service account associated with an 
application server of a registered subscriber within a signaling network supporting 
internet protocol based services. The method includes monitoring a status of said 
service account. The method further includes forwarding a request for barring from said 
application server via a direct interface to a registration server, which maintains a 
registration status of said subscriber, upon determining that disruption or termination of 
service is required. The method further includes changing a barring indication of said 
subscriber so as to bar said subscriber at said registration server by changing said 
barring indication in response to said barring request. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "forwarding a request for barring from said application server via a direct 
interface to a registration server," as recited in claim 1 1 for similar reasons as to why the 
combination of 3GPP and Kett fails to disclose, or suggest, at least, "forwarding a request 
for de-registration from said application server via a direct interface," as recited in claim 
1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
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allowed. 



xi) Claim 12 

Claim 12 is dependent on claim 1 1 , and recites further limitations. Thus, claim 12 
is patentable at least for the reasons claim 1 1 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xii) Claim 13 

Claim 1 3 is dependent on claim 1 1 , and recites further limitations. Thus, claim 1 3 
is patentable at least for the reasons claim 1 1 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xiii) Claim 14 

Claim 14 is dependent on claim 1 1 , and recites further limitations. Thus, claim 14 
is patentable at least for the reasons claim 1 1 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xiv) Claim 15 

Claim 15 recites a system for deactivating a service account of a registered 
subscriber within a signaling network supporting internet protocol based services. The 
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system includes a registration server configured to maintain a registration status of said 
subscriber. The system further includes an application server, to which said service 
account is associated, configured to monitor a status of said service account and to 
forward via a direct interface a request for barring to said registration server, upon 
determining that disruption or termination of service is required. The registration server is 
configured to change a barring indication of said subscriber to bar said subscriber in 
response to said barring request. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "an application server, to which said service account is associated, configured to 
monitor a status of said service account and to forward via a direct interface a request for 
barring to said registration server" as recited in claim 1 5 for similar reasons as to why the 
combination of 3GPP and Kett fails to disclose, or suggest, at least, "forwarding a request 
for de-registration from said application server via a direct interface" as recited in claim 
1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xv) Claim 16 

Claim 16 recites a system for deactivating a service account associated with an 
application server of a registered subscriber within a signaling network supporting 
internet protocol based services. The system includes monitoring means for monitoring 
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a status of said service account. The system further includes forwarding means for 
forwarding a request for de-registration from said application server via a direct interface 
to a registration server, which maintains a registration status of said subscriber, upon 
determining that disruption or termination of service is required. The system further 
includes changing means for changing the registration status of said subscriber so as to 
deregister said subscriber at said registration server in response to de-registration 
request. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "forwarding means for forwarding a request for de-registration from said 
application server via a direct interface to a registration server," as recited in claim 16 for 
similar reasons as to why the combination of 3GPP and Kett fails to disclose, or suggest, 
at least, "forwarding a request for de-registration from said application server via a direct 
interface," as recited in claim 1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xvh Claim 17 

Claim 17 recites a system for deactivating a service account associated with an 
application server of a registered subscriber within a signaling network supporting 
internet protocol based services. The system includes monitoring means for monitoring 
a status of said service account. The system further includes forwarding means for 
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forwarding a request for barring from said application server via a direct interface to a 
registration server, which maintains a registration status of said subscriber, upon 
determining that disruption or termination of service is required. The system further 
includes changing means for changing a barring indication of said subscriber so as to bar 
said subscriber at said registration server by changing said barring indication in response 
to said barring request.. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "forwarding means for forwarding a request for barring from said application 
server via a direct interface to a registration server," as recited in claim 17 for similar 
reasons as to why the combination of 3GPP and Kett fails to disclose, or suggest, at 
least, "forwarding a request for de-registration from said application server via a direct 
interface," as recited in claim 1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xvii) Claim 18 

Claim 18 is dependent on claim 1 , and recites further limitations. Thus, claim 18 is 
patentable at least for the reasons claim 1 1 is patentable, and further, because it recites 
additional limitations. 

Specifically, claim 18 recites "wherein said forwarding comprises forwarding said 
request over said interface directly coupling said application server and said registration 
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server." The Final Office Action relied upon two separate portions of 3GPP to support its 
erroneous position that 3GPP discloses the aforementioned limitation. The Final Office 
Action first relied upon page 43, Figure. 5.5a as allegedly disclosing forwarding a request, 
and relied upon pages 14-17, Section 4.2.4 as allegedly disclosing an interface directly 
coupling an application server and an registration server. (See Final Office Action at 
page 4). Section 4.2.4 describes an ISC interface between a Serving CSCF and a 
service platform, and Sh and Si interfaces used for communications between the 
application server and the home subscriber server ("HSS"). (See 3GPP at pages 14-17, 
Section 4.2.4). However, 3GPP fails to describe a registration message being sent over 
the Sh and Si interfaces. Instead, 3GPP merely describes that the S-CSCF receives 
de-registration information from the service platform and issues a de-registration towards 
the P-CSCF. (See 3GPP at page 43, section 5.3.2.2.2, Figure 4.4a). Because the claim 
explicitly recites that the request is forwarded over the interface directly coupling the 
application server and the registration server, Appellants respectfully submit that 3GPP 
fails to disclose, or suggest, the aforementioned limitation. Furthermore, Kett fails to cure 
the deficiencies of 3GPP because, as previously discussed, Kett merely discusses a 
direct interface between an application and a Parlay service, and fails to disclose an 
interface directly coupling an application server and a registration server. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xviii) Claim 19 

Claim 19 is dependent on claim 1 1, and recites further limitations. Thus, claim 19 
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is patentable at least for the reasons claim 11 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xix) Claim 20 

Claim 20 recites a method of deactivating a service account associated with an 
application server of a registered subscriber within a signaling network supporting 
internet protocol based services. The method includes monitoring a status of a service 
account. The method further includes forwarding a request for de-registration from said 
application server via a direct interface to a registration server upon determining that 
disruption or termination of service is required. The registration server maintains a 
registration status of said subscriber. The registration server changes said registration 
status of said subscriber so as to de-register said subscriber at said registration server in 
response to said de-registration request. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "forwarding a request for de-registration from said application server via a direct 
interface to a registration server," as recited in claim 20 for similar reasons as to why the 
combination of 3GPP and Kett fails to disclose, or suggest, at least, "forwarding a request 
for de-registration from said application server via a direct interface," as recited in claim 
1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
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allowed. 



xx) Claim 21 

Claim 21 is dependent on claim 20, and recites further limitations. Thus, claim 21 
is patentable at least for the reasons claim 20 is patentable, and further, because it 
recites additional limitations. 

Specifically, claim 21 recites "wherein said forwarding comprises forwarding said 
request over said interface directly coupling said application server and said registration 
server." The Final Office Action relied upon two separate portions of 3GPP to support its 
erroneous position that 3GPP discloses the aforementioned limitation. The Final Office 
Action first relied upon page 43, Figure. 5.5a as allegedly disclosing forwarding a request, 
and relied upon pages 14-17, Section 4.2.4 as allegedly disclosing an interface directly 
coupling an application server and an registration server. (See Final Office Action at 
page 4). Section 4.2.4 describes an ISC interface between a Serving CSCF and a 
service platform, and Sh and Si interfaces used for communications between the 
application server and the home subscriber server ("HSS"). (See 3GPP at pages 14-17, 
Section 4.2.4). However, 3GPP fails to describe a registration message being sent over 
the Sh and Si interfaces. Instead, 3GPP merely describes that the S-CSCF receives 
de-registration information from the service platform and issues a de-registration towards 
the P-CSCF. (See 3GPP at page 43, section 5.3.2.2.2, Figure 4.4a). Because the claim 
explicitly recites that the request is forwarded over the interface directly coupling the 
application server and the registration server, Appellants respectfully submit that 3GPP 
fails to disclose, or suggest, the aforementioned limitation. Furthermore, Kett fails to cure 

27 



the deficiencies of 3GPP because, as previously discussed, Kett merely discusses a 
direct interface between an application and a Parlay service, and fails to disclose an 
interface directly coupling an application server and a registration server. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xxi) Claim 22 

Claim 22 is dependent on claim 20, and recites further limitations. Thus, claim 22 
is patentable at least for the reasons claim 20 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xxii) Claim 23 

Claim 3 is dependent on claim 20, and recites further limitations. Thus, claim 23 is 
patentable at least for the reasons claim 20 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xxiii) Claim 24 

Claim 24 is dependent on claim 20, and recites further limitations. Thus, claim 24 
is patentable at least for the reasons claim 20 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 
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xxiv) Claim 25 

Claim 25 recites a method of deactivating a service account associated with an 
application server of a registered subscriber within a signaling network supporting 
internet protocol based services. The method includes receiving from said application 
server via a direct interface a request for de-registration at a registration server, which 
maintains a registration status of said subscriber. The method further includes changing 
the registration status of said subscriber so as to de-register said subscriber at said 
registration server in response to said de-registration request. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "receiving from said application server via a direct interface a request for 
de-registration at a registration server" as recited in claim 25 for similar reasons as to 
why the combination of 3GPP and Kett fails to disclose, or suggest, at least, "forwarding 
a request for de-registration from said application server via a direct interface" as recited 
in claim 1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xxv) Claim 26 

Claim 26 is dependent on claim 25, and recites further limitations. Thus, claim 26 
is patentable at least for the reasons claim 25 is patentable, and further, because it 
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recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xxvi) Claim 27 

Claim 27 recites a method of deactivating a service account associated with an 
application server of a registered subscriber within a signaling network supporting 
internet protocol based services. The method includes monitoring a status of said 
service account. The method further includes forwarding a request for barring from said 
application server via a direct interface to a registration server upon determining that 
disruption or termination of service is required. The registration server maintains a 
registration status of said subscriber. The registration server changes a barring 
indication of said subscriber so as to bar said subscriber at said registration server by 
changing said barring indication in response to said barring request. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "forwarding a request for barring from said application server via a direct 
interface to a registration server," as recited in claim 27 for similar reasons as to why the 
combination of 3GPP and Kett fails to disclose, or suggest, at least, "forwarding a request 
for de-registration from said application server via a direct interface" as recited in claim 
1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 
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xxvii) Claim 28 

Claim 28 is dependent on claim 27, and recites further limitations. Thus, claim 28 
is patentable at least for the reasons claim 27 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xxviii) Claim 29 

Claim 29 is dependent on claim 27, and recites further limitations. Thus, claim 29 
is patentable at least for the reasons claim 27 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xxix) Claim 30 

Claim 30 recites a method of deactivating a service account associated with an 
application server of a registered subscriber within a signaling network supporting 
internet protocol based services. The method includes receiving from said application 
server via a direct interface a request for barring to a registration server, which maintains 
a registration status of said subscriber. The method further includes changing a barring 
indication of said subscriber so as to bar said subscriber at said registration server by 
changing said barring indication in response to said barring request. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
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and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "receiving from said application server via a direct interface a request for barring 
to a registration server," as recited in claim 30 for similar reasons as to why the 
combination of 3GPP and Kett fails to disclose, or suggest, at least, "forwarding a request 
for de-registration from said application server via a direct interface," as recited in claim 
1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xxx) Claim 31 

Claim 31 is dependent on claim 30, and recites further limitations. Thus, claim 31 
is patentable at least for the reasons claim 30 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xxxi) Claim 32 

Claim 32 recites a registration server for deactivating a service account of a 
registered subscriber. The registration server includes a storage configured to maintain 
a registration status of said subscriber. The registration server further includes an 
updating unit configured to change the registration status of said subscriber so as to 
de-register said subscriber in response to a de-registration request forwarded from an 
application server via a direct interface to said registration server. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
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While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "an updating unit configured to change the registration status of said subscriber 
so as to de-register said subscriber in response to a de-registration request forwarded 
from an application server via a direct interface to said registration server," as recited in 
claim 32 for similar reasons as to why the combination of 3GPP and Kett fails to disclose, 
or suggest, at least, "forwarding a request for de-registration from said application server 
via a direct interface," as recited in claim 1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xxxii) Claim 33 

Claim 33 is dependent on claim 32, and recites further limitations. Thus, claim 33 
is patentable at least for the reasons claim 32 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and the claim allowed. 

xxxiii) Claim 34 

Claim 34 recites a registration server for deactivating a service account of a 
registered subscriber. The registration server includes means for maintaining a 
registration status of said subscriber. The registration server further includes means for 
changing the registration status of said subscriber so as to de-register said subscriber in 
response to a de-registration request forwarded from an application server via a direct 
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interface to said registration server. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "means for changing the registration status of said subscriber so as to de-register 
said subscriber in response to a de-registration request forwarded from an application 
server via a direct interface to said registration server," as recited in claim 34 for similar 
reasons as to why the combination of 3GPP and Kett fails to disclose, or suggest, at 
least, "forwarding a request for de-registration from said application server via a direct 
interface," as recited in claim 1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xxxiv) Claim 35 

Claim 35 recites an application server for deactivating a service account of a 
registered subscriber. The application server includes a forwarding unit configured to 
forward a request for de-registration from said application server via a direct interface to 
a registration server, upon determining that disruption or termination of service is 
required. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "a forwarding unit configured to forward a request for de-registration from said 
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application server via a direct interface to a registration server," as recited in claim 35 for 
similar reasons as to why the combination of 3GPP and Kett fails to disclose, or suggest, 
at least, "forwarding a request for de-registration from said application server via a direct 
interface," as recited in claim 1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 

xxxv) Claim 36 

Claim 36 recites an application server for deactivating a service account of a 
registered subscriber. The application server includes means for monitoring a status of 
said service account. The application server further includes means for forwarding a 
request for de-registration from said application server via a direct interface to a 
registration server, upon determining that disruption or termination of sen/ice is required. 

The descriptions of 3GPP and Kett, as discussed above are incorporated herein. 
While each of the claims have their own scope, Appellants respectfully submit that 3GPP 
and Kett, whether considered individually or in combination, fail to disclose, or suggest, 
at least, "means for forwarding a request for de-registration from said application server 
via a direct interface to a registration server," as recited in claim 36 for similar reasons as 
to why the combination of 3GPP and Kett fails to disclose, or suggest, at least, 
"forwarding a request for de-registration from said application server via a direct 
interface," as recited in claim 1, as discussed in Section VII, i. 

Therefore, it is respectfully requested that this rejection be reversed and the claim 
allowed. 
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For all of the above noted reasons, it is strongly contended that certain clear 
differences exist between the present invention as claimed in claims 1-6 and 8-36 and the 
prior art relied upon by the Examiner. It is further contended that these differences are 
more than sufficient that the present invention would not have been obvious to a person 
having ordinary skill in the art at the time the invention was made. 

This final rejection being in error, therefore, it is respectfully requested that this 
honorable Board of Patent Appeals and Interferences reverse the Examiner's decision in 
this case and indicate the allowability of application claims 1-6 and 8-36. 
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In the event that this paper is not being timely filed, the applicants respectfully 
petition for an appropriate extension of time. Any fees for such an extension together 
with any additional fees which may be due with respect to this paper may be charged to 
Counsel's Deposit Account 50-2222. 
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APPENDIX 1 
CLAIMS ON APPEAL 

1. (Previously Presented) A method of deactivating a service account 
associated with an application server of a registered subscriber within a signaling network 
supporting internet protocol based services, the method comprising: 

monitoring a status of a service account; 

forwarding a request for de-registration from said application server via a direct 
interface to a registration server, which maintains a registration status of said subscriber, 
upon determining that disruption or termination of service is required; and 

changing the registration status of said subscriber so as to de-register said 
subscriber at said registration server in response to said de-registration request. 

2. (Previously Presented) A method according to claim 1, wherein said 
forwarding step comprises forwarding said request over said interface directly coupling 
said application server and said registration server. 

3. (Previously Presented) A method according to claim 1, wherein said 
forwarding comprises forwarding said request to said registration server comprising a 
home subscriber server of an internet protocol multimedia subsystem. 

4. (Previously Presented) A method according to claim 3, wherein said 
forwarding comprises forwarding said request over said interface comprising an Sh 
reference point. 
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5. (Previously Presented) A method according to claim 3, wherein said 
forwarding comprises forwarding said request in a profile update request command. 

6. (Previously Presented) A method according to claim 5, further comprising 
indicating de-registration by setting an updated registration status to a predetermined 
value. 

7. (Cancelled) 

8. (Previously Presented) A system for deactivating a service account of a 
registered subscriber within a signaling network supporting internet protocol based 
services, said system comprising: 

a registration server configured to maintain a registration status of said subscriber; 

and 

an application server, to which said service account is associated, configured to 
monitor a status of said service account and to forward via a direct interface a request for 
de-registration to said registration server, upon determining that disruption or termination 
of sen/ice is required, 

wherein said registration server is configured to change the registration status of 
said subscriber so as to de-register said subscriber in response to said de-registration 
request. 
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9. (Original) A system according to 8, wherein said registration server is a 
home subscriber server. 

10. (Original) A system according to 8, wherein said signaling network 
comprises an internet protocol multimedia subsystem. 

11. (Previously Presented) A method of deactivating a service account 
associated with an application server of a registered subscriber within a signaling network 
supporting internet protocol based services, the method comprising: 

monitoring a status of said service account; 

forwarding a request for barring from said application server via a direct interface 
to a registration server, which maintains a registration status of said subscriber, upon 
determining that disruption or termination of service is required; and 

changing a barring indication of said subscriber so as to bar said subscriber at said 
registration server by changing said barring indication in response to said barring request. 

12. (Previously Presented) A method according to claim 11, wherein said 
forwarding comprises forwarding said request to said registration server comprising a 
home subscriber server of an internet protocol multimedia subsystem. 

13. (Previously Presented) A method according to claim 12, wherein said 
forwarding comprises forwarding said requests in a profile update request command. 
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14. (Previously Presented) A method according to claim 13, further comprising 
indicating barring by adding the barring indication to a definition of a public identity. 

15. (Previously Presented) A system for deactivating a service account of a 
registered subscriber within a signaling network supporting internet protocol based 
services, said system comprising: 

a registration server configured to maintain a registration status of said subscriber; 

and 

an application server, to which said service account is associated, configured to 
monitor a status of said service account and to forward via a direct interface a request for 
barring to said registration server, upon determining that disruption or termination of 
service is required, 

wherein said registration server is configured to change a barring indication of said 
subscriber to bar said subscriber in response to said barring request. 

16. (Previously Presented) A system for deactivating a service account 
associated with an application server of a registered subscriber within a signaling network 
supporting internet protocol based services, the system comprising: 

monitoring means for monitoring a status of said service account; 

forwarding means for forwarding a request for de-registration from said application 
server via a direct interface to a registration server, which maintains a registration status 
of said subscriber, upon determining that disruption or termination of service is required; 
and 
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changing means for changing the registration status of said subscriber so as to 
deregister said subscriber at said registration server in response to de-registration 
request. 

17. (Previously Presented) A system for deactivating a service account 
associated with an application server of a registered subscriber within a signaling network 
supporting internet protocol based services, the system comprising: 

monitoring means for monitoring a status of said service account; 

forwarding means for forwarding a request for barring from said application server 
via a direct interface to a registration server, which maintains a registration status of said 
subscriber, upon determining that disruption or termination of service is required; and 

changing means for changing a barring indication of said subscriber so as to bar 
said subscriber at said registration server by changing said barring indication in response 
to said barring request. 

18. (Previously Presented) A method according to claim 11, wherein said 
forwarding comprises forwarding said request over said interface directly coupling said 
application server and said registration server. 

19. (Previously Presented) A method according to claim 12, wherein said 
forwarding comprises forwarding said request over said interface comprising an Sh 
reference point. 
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20. (Previously Presented) A method of deactivating a service account 
associated with an application server of a registered subscriber within a signaling network 
supporting internet protocol based services, the method comprising: 

monitoring a status of a service account; and 

forwarding a request for de-registration from said application server via a direct 
interface to a registration server upon determining that disruption or termination of service 
is required, 

wherein the registration server maintains a registration status of said subscriber, 

and 

wherein the registration server changes said registration status of said subscriber 
so as to de-register said subscriber at said registration server in response to said 
de-registration request. 

21. (Previously Presented) A method according to claim 20, wherein said 
forwarding comprises forwarding said request over said interface directly coupling said 
application server and said registration server. 

22. (Previously Presented) A method according to claim 20, wherein said 
forwarding comprises forwarding said request to said registration server comprising a 
home subscriber server of an internet protocol multimedia subsystem. 

23. (Previously Presented) A method according to claim 22, wherein said 
forwarding comprises forwarding said request over said interface comprising an Sh 
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reference point. 

24. (Previously Presented) A method according to claim 22, wherein said 
forwarding comprises forwarding said request in a profile update request command. 

25. (Previously Presented) A method of deactivating a service account 
associated with an application server of a registered subscriber within a signaling network 
supporting internet protocol based services, the method comprising: 

receiving from said application server via a direct interface a request for 
de-registration at a registration server, which maintains a registration status of said 
subscriber; and 

changing the registration status of said subscriber so as to de-register said 
subscriber at said registration server in response to said de-registration request. 

26. (Previously Presented) A method according to claim 25, further comprising 
indicating de-registration by setting an updated registration status to a predetermined 
value. 

27. (Previously Presented) A method of deactivating a service account 
associated with an application server of a registered subscriber within a signaling network 
supporting internet protocol based services, the method comprising: 

monitoring a status of said service account; and 

forwarding a request for barring from said application server via a direct interface 
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to a registration server upon determining that disruption or termination of service is 
required, 

wherein the registration server maintains a registration status of said subscriber, 
and wherein the registration server changes a barring indication of said subscriber 

so as to bar said subscriber at said registration server by changing said barring indication 

in response to said barring request. 

28. (Previously Presented) A method according to claim 27, wherein said 
forwarding comprises forwarding said request to said registration server comprising a 
home subscriber server of an internet protocol multimedia subsystem. 

29. (Previously Presented) A method according to claim 28, wherein said 
forwarding comprises forwarding said request in a profile update request command. 

30. (Previously Presented) A method of deactivating a service account 
associated with an application server of a registered subscriber within a signaling network 
supporting internet protocol based services, the method comprising: 

receiving from said application server via a direct interface a request for barring to 
a registration server, which maintains a registration status of said subscriber; and 

changing a barring indication of said subscriber so as to bar said subscriber at said 
registration server by changing said barring indication in response to said barring request. 

31 . (Previously Presented) A method according to claim 30, further comprising 
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indicating barring by adding the barring indication to a definition of a public identity. 

32. (Previously Presented) A registration server for deactivating a service 
account of a registered subscriber, said registration server comprising: 

a storage configured to maintain a registration status of said subscriber; and 
an updating unit configured to change the registration status of said subscriber so 
as to de-register said subscriber in response to a de-registration request forwarded from 
an application server via a direct interface to said registration server. 

33. (Previously Presented) The registration server according to claim 32, 
wherein said registration server is a home subscriber server. 

34. (Previously Presented) A registration server for deactivating a service 
account of a registered subscriber, said registration server comprising: 

means for maintaining a registration status of said subscriber; and 

means for changing the registration status of said subscriber so as to de-register 

said subscriber in response to a de-registration request forwarded from an application 

server via a direct interface to said registration server. 

35. (Previously Presented) An application server for deactivating a service 
account of a registered subscriber, said application server comprising: 

a forwarding unit configured to forward a request for de-registration from said 
application server via a direct interface to a registration server, upon determining that 
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disruption or termination of service is required. 

36. (Previously Presented) An application server for deactivating a service 
account of a registered subscriber, said application server comprising: 

means for monitoring a status of said service account; and 

means for forwarding a request for de-registration from said application server via 
a direct interface to a registration server, upon determining that disruption or termination 
of service is required. 
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APPENDIX 2 
EVIDENCE APPENDIX 

No evidence under section 37 C.F.R. 1.130, 1.131, or 1.132 has been entered or 
will be relied upon by Appellants in this appeal. 



48 



APPENDIX 3 
RELATED PROCEEDINGS APPENDIX 

No decisions of the Board or of any court have been identified under 37 C.F.R. 
§41 .37(c)(1)(H) 
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